perf(app): compose the middleware chain once instead of per request - #4559

Resolves #4443

Every request in a Nitro app passes through a chain of middleware: route rules from your config (redirects, headers, cors, ...), global middleware from server/middleware/, routed middleware, and finally the route handler.

Until now, Nitro rebuilt that list on every single request and told h3 to walk it step by step. h3 can do better: it can build the chain once and reuse it for every request, but only if Nitro stops overriding its internal ~getMiddleware hook. This PR removes that override, as proposed in #4443.

How it works now

• Nitro registers its middleware on h3 in the same order as before: route rules, then global, then routed middleware. h3 composes them once on the first request.
• Route rules and routed middleware depend on the request path, so each of them is a single small middleware that looks up what matches and runs a chain that is composed once per distinct set of matched handlers. The lookup is cached by which handlers matched, not by URL, so apps with many unique URLs (/users/:id, crawlers, and so on) do not pay for cache misses.
• event.context.routeRules is now filled in when h3 resolves the route, before any middleware runs. So it is available in every middleware, including middleware a plugin adds to the front of the chain.
• Nitro's own two wrapper middleware are hidden from h3 tracing, so the spans you see are still only your middleware and routes, as before.
• After all plugins have run at startup, Nitro tells h3 to rebuild its cached chain. This covers plugins that send a warm-up request during startup, before a later plugin (for example tracing) has adjusted the chain.

Anything to watch out for

• If a plugin adds middleware to the front of nitroApp.h3["~middleware"], that middleware now runs before route rules, not after. It should not assume redirects or headers from route rules have already been applied. This is a private API and nothing in Nitro relies on it, but at least one ecosystem plugin (nuxt-ai-ready) does this, so it is mentioned in the plugins docs.
• If a plugin changes that array after the first request, it must also reset nitroApp.h3["~dispatch"] and nitroApp.h3["~composed"] to undefined, because h3 only composes the chain once. This is also documented.
• The old override had a branch for route.data.middleware. Nitro never generates that key, so the branch was dead code and was removed. h3 handles route-level middleware itself when a route has it.

Tests and docs

• The shared e2e test now checks the full order in-band: route rules, then global, then routed middleware. The fixture's global middleware records whether event.context.routeRules was already set.
• New unit tests cover the generated template shape and the two runtime wrappers (compose once, pass through when nothing matches, stop on short-circuit).
• The lifecycle and plugins docs describe when route rules are resolved and what plugins that touch the middleware array need to do.
• pnpm lint, pnpm typecheck, and the suite pass on both builders. test/minimal has no route rules or routed middleware, so bundle-size budgets are unchanged.

Once this lands, h3js/h3#1525 can drop its compatibility path for the ~getMiddleware override, which is the end state described in the issue.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.